Before the Third Generation Partnership Project (3GPP) Release 6, a radio link control (RLC) protocol data unit (PDU) was a fixed size (e.g., “336” or “656” bits). When a packet from a higher layer was larger than a RLC payload size, RLC needed to segment a service data unit (SDU) (e.g., into “320” or “640” bits) in order to fit a RLC PDU size. On the other hand, media access control (MAC) could perform concatenation, but not segmentation.
Such a small and fixed RLC PDU size was not efficient for large packets generated in the application layer, and prevented user equipment (UE) from obtaining higher user throughput. Thus, in 3GPP Release 7, the concept of a flexible RLC was introduced. Flexible RLC means that the RLC PDU size can be of any length below a predefined maximum RLC PDU size (e.g., “1500” bytes). With flexible RLC, the RLC PDU size can be much larger. In many cases a maximum supported transport block (TB) size at Layer 1 is unable to contain an entire RLC PDU. Therefore, MAC segmentation becomes necessary. Downlink segmentation at the MAC layer was introduced in 3GPP Release 7, and uplink segmentation at MAC layer was introduced in 3GPP Release 8. According to the current 3GPP specification, when segmentation is needed in an uplink, a final transport block size after enhanced dedicated channel (E-DCH) transport format combination (ETFC or E-TFC) selection (e.g., selection of an appropriate transport format for transmission of data on E-DCH) is determined to be a minimum of a maximum transport block size that is supported by current radio conditions and a size of the RLC PDU in the user equipment buffer (e.g., final_TB_size=min(maximum supported TB size, RLC PDU size)).
As an alternative to MAC segmentation, a new technique called radio-aware RLC segmentation has been defined for the uplink. This technique attempts to address the same problem (e.g., that the incoming RLC payload size be larger than a maximum transport block size after ETFC selection). However, it is the RLC layer, and not the MAC layer, that performs the segmentation. In radio-aware RLC segmentation, the final transport block size after ETFC selection is determined to be the minimum of the maximum transport block size that is supported by current radio conditions and a size of the RLC SDU in the user equipment buffer (e.g., final_TB_size=min(maximum supported TB size, RLC SDU size)).
Unfortunately, ETFC selection behavior during segmentation experiences problems regardless of whether MAC performs the segmentation or radio-aware RLC performs the segmentation. In some segmentation methods, the user equipment selects a transport block that can transmit as many bits as possible in a current transmission time interval (TTI) for a RLC PDU or a RLC SDU without considering how many bits are left in the RLC PDU or in the RLC SDU that need to be transmitted in a next TTI. These segmentation methods do not experience problems if a number of bits left in the RLC PDU or in the RLC SDU is large enough. However, such segmentation methods are not optimal if the number of bits left in the RLC PDU or in the RLC SDU is smaller than a minimum transport block size defined in an ETFC table.
For example, although a first transport block (e.g., transmitted in a first TTI) fits a first MAC PDU, a mismatch occurs between a second transport block (e.g., transmitted in a next TTI) and a second MAC PDU. Large padding (e.g., extra space) exists in the second transport block because a remaining portion of a RLC PDU or a RLC SDU is too small after segmentation. Although the remaining portion of the RLC PDU or the RLC SDU may wait in the buffer and concatenate with an incoming SDU at a later time, such an arrangement is not always acceptable for delay sensitive services (e.g., voice over Internet protocol (VoIP), etc.). Since an uplink resource is limited, too much padding is a waste of a valuable resource. Another drawback with such segmentation methods is that a difference between the two transport block sizes may be very large, which may result in a power jump (or power surge) in the user equipment.